The Smalltalk Report 


The International Newsletter for Smalltalk Programmers 

July-August 1993 Volume 2 Number 9 


Smalltalk 



TECHNIQUES 


By Roxie Rochat 
& Juanita Ewing 


Contents: 

Feature 

I Smalltalk debugging 
techniques 

by Roxie Rochat A Juanita 
Ewing 

Articles 

4 Debugging objects 
by Bob Hinkle, Vicki Jones, & 
Ralph E Johnson 

B Applications of Smalltalk in 
scientific and engineering 
computation 
by Richard L. Peskin 

Columns 

II The Best of comp. lang. Smalltalk.] 
Good code, bad hacks 

by Alan Knight 

15 Smalltalk Idioms: Inheritance: 
the rest of the story 
by Kent Beck 

26 Product News and Highlights 


E 


Xpert Smalltalk users are characterized not only by their program¬ 
ming skills, but by how quickly they locate and correct errors. Not 
only do they use debugging skills to find bugs, but also to under¬ 
stand existing code. To reuse code effectively, you have to under¬ 
stand it, so debugging skills are important tools for maximizing 
reuse and minimizing work. 

This article describes debugging techniques for both Objectworks\Smalltalk 
and Smalltalk/V. Although written for novice Smalltalk users, it assumes a basic 
familiarity with Smalltalk terminology and the environment, including browsers 
and debuggers. 

Many expressions in this paper are common to Objectworks and Digitalk 
Smalltalk systems. Expressions that are not annotated apply to both Smalltalk sys¬ 
tems. Unless otherwise noted, the Objectworks expressions given in this article are 
applicable for: 

■ Objectworks\Smalltalk4.1 

■ VisualWorks 1.0 

■ ENVY/Developer rl.41a for Objectworks\Smalltalk and VisualWorks. 

The Smalltalk/V expressions have been tested under: 

■ Version 2.0 of Smalltalk/V for OS/2 

■ Version 2.0 of Smalltalk/V for Windows 

■ ENVY/Developer rl.41a for Smalltalk/V for Windows 

If you are using other versions of Smalltalk, use the expressions presented in this 
article as a starting point. 

WHO AM I? 

A major component of the debugging process is the collection of information 
about the objects and their current state. Transcript messages allow you to gather 
information about objects over time. Inspectors allow you to see objects and their 
internals in a static state. Careful planning with respect to naming and object 
identity can help you focus on easily collecting relevant information. This section 
reviews debugging techniques involving the Transcript, inspectors, and factors re¬ 
lating to object identity. 

hello world, or printf, in Smalltalk 

The Smalltalk equivalent of the C printf function is to write to the Transcript win¬ 
dow. (You do leave your Transcript open, don’t you? The system writes error 
messages to the Transcript so if you collapse or close it, sooner or later, you’ll be 
sorry.) 

Information you print in the Transcript can be used to determine when a par¬ 
ticular method is called, to examine arguments, or to examine data calculated by 

continued on page 18 .. 
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John Pugh Paul White 

D evelopers who use Smalltalk have always had a real love/hate relationship with their devel¬ 
opment environment. We’ve always been fascinated listening to Smalltalkers describe the 
toolset in their environment. When describing Smalltalk to “outsiders,” they defend it 
with an emotional fervor, noting how flexible it is and how rich a toolset it actually pro¬ 
vides. But if you have a chance to speak with these same people alone, you’ll hear a very 
different story. The fact is that the base Smalltalk development environment is in desperate 
need of a major overhaul. It has become Smalltalk’s “legacy system.” One of the first things 
that appealed to us about Smalltalk back in the early days was its rich development envi¬ 
ronment—it was definitely the best on the block. Since then, no significant changes have 
been made to the way in which people interact with the system. Sure, minor improvements 
have been made at times, but there have been no qualitative improvements to the browser, 
the inspector, or the debugger- Even the tools that do exist need to be more polished. (Ever 
listen to someone use the “Find Class” option in Digitalk’s browser—the groans over a lack 
of wild card are universal). Even team development tools such as Team/V and ENVY don’t 
improve to any significant extent the way in which we interact with Smalltalk. 

So why don’t we see better toolsets coming to market? We suspect the answer is simple: a 
lack of motivation on the part of the vendors. There is a greater return to be made by provid¬ 
ing add-on facilities such as interface builders and database interfaces than there is by aug¬ 
menting the tools that already exist in the base image. Will third-party developers take up the 
challenge? We hope so, but we are not terribly optimistic. Perhaps the forthcoming Object 
Explorer tool form First Class Software, which attempts to visualize the relationships between 
objects, will set a trend. Of course, many Smalltalk programming shops have built “in-house” 
extensions to the environment that they use on their projects and those of their clients. But 
most organizations don’t want to be tool builders, they 1 re application developers. 

On a more positive note, four of the articles in this issue do illustrate just how rich an en¬ 
vironment Smalltalk has. Each takes a different perspective, with two focusing directly on 
the debugging process and the techniques that can be used to understand what is taking 
place inside your systems. Roxie Rochat and Juanita Ewing are featured this month with 
their hints on debugging. They have included a number of debugging techniques, including 
ones for debugging code that does not allow for the normal “self halt” approach to work. 

Also on the topic of debugging, Bob Hinkle, Vicki Jones, and Ralph Johnson return 
this month with a description of how Smalltalk can be extended in ways that will allow for 
non-intrusive debugging to be carried out. 

Alan Knight and Kent Beck also touch on the issue of debugging with Smalltalk. Kent re¬ 
turns to his discussion of the conflicting roles played by inheritance in Smalltalk and intro¬ 
duces two new patterns that describe rules that can be applied when making inheritance deci¬ 
sions. Alan tackles the issue of recognizing “good code” by characterizing the elements of 
good coding techniques. 

Finally, Richard Peskin provides us with a glimpse into work that is being done to 
make Smalltalk more applicable to scientific and engineering computing. As he points 
out, this area has not received much attention from the Smalltalk community lately, even 
though much of Smalltalk’s early history involved serving this community. 
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I Windo wB uilder 

The New Power in Smalltalk/VInterface Development 
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Smalltalk/V developers have 
WindowDuilder as an 
essential tool for develop¬ 
ing sophisticated user inter¬ 
faces. Tedious hand coding 
of interfaces is replaced by 
interactive visual composi¬ 
tion. Since its initial release, 
WindowBuilder has 
become the industry stan¬ 
dard GUI development tool 
for the Smalltalk/V environ¬ 
ment. Now Objectshare 
brings you a whole new 
level of capability with 
WindowBuilder Pro! New 
functionality and power 
abound in this next genera¬ 
tion of WindowBuilder. 


come 


to rely on WindowBuilder Pro/V 


is 


available on Windows for S295 
and OS/2 for $495. Our stan¬ 
dard WindowBuilder/V is 
still available on Windows 
for $149-95 and OS/2 for 
$295. We offer full value 
trade-in for our 
WindowBuilder customers 
wanting to move up to Pro, 
These products are also 
available in 
ENVY »/Developer and 
Team/V™ compatible for¬ 
mats. As with all of our 
products, WindowBuilder 
Pro comes with a 30 day 
money back guarantee, full 
source code and no Run¬ 
Time fees. 


Some of the exciting new features... 


• ComposilePanes: Create custom controls as composites 

of other controls, treated as 
a single object, allowing the 
developer higher leverage 
of reusable widgets. 
CompositePanes can be 
used repeatedly and 
because they are Class based, they can be easily sub¬ 
classed; changes in a CompositePane are reflected any¬ 
where they are used. 



• Morphing: Allows the developer to quickly change 
1 Smaiitait M from one type of control 
wjndo-BuHdtr ■ tQ ano ther, allowing for 

p powerful "what-if" style 

_H visual development. The 

flexibility allowed by 

morphing will greatly enhance productivity. 


-Skills- 

O Smalltalk 
O WindowBuilder 
O Other 


• ScrapBook: Another new feature to leverage visual 
component reuse, ScrapBooks provide a mechanism for 

developers to quickly 
store and retrieve pre¬ 
defined sets of compo¬ 
nents. The ScrapBook 
is a catalog of one's 
favorite interface com¬ 
ponents, organized 

into chapters and pages. 



• Rapid Prototyping capa¬ 
bilities: With the new link¬ 
ing capabilities, a develop¬ 
er can rapidly prototype a 
functional interface without 
writing a single line of 
code. LinkButtons and 
LinkMenus provide a pow¬ 
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erful mechanism for linking 
windows together and speci¬ 
fying flow of control. 
ActionButtons and 
ActionMenues provide a 
mechanism for developers to 
attach, create, and reuse 
actions without having to write code. These features 
greatly enhance productivity during prototyping. 

• Toolbar: Developers can Create sophisticated toolbars 



just like the ones in the WindowBuilder Pro tool itself. 

• Other new features include: enhanced duplication and 
cut/paste functions, size and position indicators, 
enhanced framing specification, Parent-Child window 
relationship specification, enhanced EntryField with char¬ 
acter and field level validation, and much more... 

• Add-in Manager: Allows developers to easily integrate 
extensions into WindowBuilder Pro's open architecture. 



Catch the excitement, go Pro! 

Call Objectshare for more information. 

(408) 727-3742 


Objectshare Systems, Inc 5 Town & Country Village 

Fax: (408)727-6324 Suite 735 

CompuServe 76436,1063 San Jose, CA 95128-2026 


WindowBuilder and WindowBuilder Pro are trademarks of Objectshare Systems, Inc. All other brand and product names are registered trademarks of Ihair respective companies 












Debugging 

objects 


Bob Hinkle, Vicki Jones, and 
Ralph E. Johnson 


s the premier object-oriented programming lan¬ 
guage, Smalltalk should give programmers easy 
access to objects. However, during debugging it 
can be very difficult to get your hands on a par¬ 
ticular object. For example, suppose you’re devel¬ 
oping a program that stores some objects in an OrderedCollec- 
tion, but when it tries to retrieve them later, some are missing. 
You might like to add debugging code to OrderedCollection 
methods such as add: and remove: to detect when objects are 
taken out of the OrderedCollection, but any changes would affect 
every OrderedCollection in the system, bringing your image to a 
crashing halt. This article will show how to solve this and simi¬ 
lar problems by letting you modify code and add breakpoints 
that affect only one particular object, rather than all objects in 
a given class.This approach of defining only object-specific 
methods is similar to what Kent Beck has described. 1 ' 2 Our so¬ 
lution relies on the use of a new kind of class and on some 
small but powerful variations on CompiledMethods and Compil¬ 
ers. Besides being useful in their own right, we feel these exten¬ 
sions again illustrate (as in our previous articles 3 ' 4 ) how power¬ 
ful Smalltalk’s reflective features are, as they allow 
programmers to adapt and extend the environment to suit 
their needs. The solution described here is specific to 
Smalltalk-80, since it relies on Smalltalk-80’s architecture for 
classes, metaclasses, the compiler, and compiled methods and 
on the complete availability of source code for these system el- 
men' 4 As a result, our extensions may not apply to Smalltalk 
V er,. onments, although something similar may be possible. 

LIGHTWEIGHT CLASSES 

The first step to debugging objects is to be able to modify 
methods on a per-object basis. In Smalltalk, methods for an 


* Source code for the object debugging package Ls available by anonymous ftp from 
st.cs.uiuc.edu. Look for the Fde ObjectDebugging.st in pub/stB0_r41. 


object are defined in that object’s class and are stored in the 
class’s method dictionary. To change a method for a particular 
object requires that the object have its own private class. We 
will give an object that we want to debug its own class by in¬ 
serting a new class between the object and its real class. We 
could create a (perhaps temporary or anonymous) instance of 
class Class for this purpose, but that’s a little heavy-handed: In¬ 
stances of Class have many instance variables and a lot of be¬ 
havior aren’t needed for our purposes. For example. Class adds 
variables and functionality to define new class and pool vari¬ 
ables. In addition. Class inherits from ClassDescription variables 
and code to support adding new instance variables and class 
organizations. All of this is unnecessary for a lightweight class, 
so we defined LightweightClass to be a subclass of Behavior. Be¬ 
havior is the superclass of ClassDescription, and it defines the 
code needed for the interpreter to do method lookup. (For 
more information on the roles of Behavior, Class, and ClassDe¬ 
scription, refer to the chapter titled “Protocol for Classes” in 
Reference 5.) Since Behavior is a simpler starting point, in¬ 
stances of LightweightClass will be smaller than instances of 
Class and will require less memory and time to allocate, initial¬ 
ize, and finalize. That makes it easier and less expensive to cre¬ 
ate lightweight classes on the fly to modify, even if only tem¬ 
porarily, some object’s behavior. 

Before explaining LightweightClass in detail, it’s helpful to 
review the way things work normally in Smalltalk. When an 
object is sent a message, the system tries to find a method cor¬ 
responding to the message’s selector in the method dictionary 
of the object’s class. If no such method exists, the system will 
look in that class’s superclass, and so on up the chain of super¬ 
classes until a method is found or the end of the chain is 
reached. Furthermore, when a method is added to a class or 
changed, the new code is compiled by an instance of the class’s 
compilerClass (which by default in the system is SmalltalkCom- 
piler). The result of compiling is an instance of CompiledMethod, 
which will be stored in the class’s method dictionary with its 
selector as its key. The source code for the method is not stored 
directly in the CompiledMethod, but, instead, is written into the 
change log, and the CompiledMethod is given a pointer to its file 
and offset. 

Our implementation of lightweight classes changes this 
normal scenario in three ways. The first and most important 
change inserts a LightweightClass in between an object and its 
real class (or what we will call original class, since it was the 
class by which the object was originally created), with the ob¬ 
ject’s class being changed to the LightweightClass, and the 
LightweightClass 1 superclass set to the object’s original class. In 
this way, any message sent to the object will first be looked up 
in the LightweightClass's method dictionary. If a method is 
found there, it will be used to respond to the message, and it 
will be unique to that particular object. Otherwise, message 
lookup will continue to the LightweightClass 1 superclass—the 
object’s original class—and, hence, will proceed as usual for 
objects of that class. Figure 1 illustrates this relationship be¬ 
tween an object, its original class, and its lightweight class. 
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Figure 1. The relationship between an object, its original class, and its 
lightweight class. 

In Figure 1, when the day message is sent to the object 
marked A, a corresponding method is searched for starting in 
Date, the object’s class. This method returns the value of the 
day instance variable, which (for A) is 97. However, when the 
day message is sent to object B, message lookup begins in its 
class, which is an instance of LightweightClass. The method in 
the lightweight class’s method dictionary is defined to return 
42. Thus, object B behaves differently from A and all other in¬ 
stances of Date. 

The two other changes pertain to source code management. 
The code for methods in lightweight classes can’t be stored in 
the change log, since the lightweight class isn't named in the 
system dictionary, and it has no category or protocols like nor¬ 
mal classes. (And in any case, the lightweight class may be an 
entirely dynamic object that is created while running a pro¬ 
gram, but which does not persist from one programming ses¬ 
sion to the next, so that storing code for it in the change log 
would make no sense.) Instead, we store the code directly with 
the method it produces, which required us to create a new kind 
of compiled method, CompiledMethodWithSource. Finally, to 
produce these kinds of compiled methods, we exploited the 
“pluggability” of the compiler and created a new subclass of 
SmalltalkCompiler. We’ll describe these two changes after first 
looking at LightweightClass in detail. 

As a subclass of Behavior, LightweightClass adds only one in¬ 
stance variable, name, which is convenient for telling 
lightweight classes apart. In addition to accessor methods for 
this variable, LightweightClass defines three other methods of 
interest: mitializeWithSuper:, which initializes a new lightweight 
class; compile:notifyinglifFail:, which adds a new method to a 
lightweight class; and compilerClass, which defines the kind of 
compiler to use for methods in a lightweight class. 

A new lightweight class is normally created by sending 
becomelightweight to an object. This method is defined in Ob¬ 
ject as follows: 

becomelightweight 

| lightweightClass | 

self LightweightClass isNil 
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ifTrue: [ 

lightweightClass := 

LightweightClass newWithSuper: self class, 
self chang eClassToThatOf: lightweightClass basicNew] 


If the receiver of this message already has a lightweight class, 
nothing more is done. Otherwise, newWithSuper: is sent to cre¬ 
ate a new lightweight class whose superclass will be the receiver 
object’s original class. The message changeClassToThatOf: is then 
sent to the receiver to insert the lightweight class before the ob¬ 
ject’s original class. Because some objects (notably immutable 
objects like SmalUntegers, Characters, true, and false) can’t have 
their class changed, becomeLightweight can’t be sent to them, 
but it can be sent to all others. 

The newWithSuper: method creates a new lightweight class 
and then sends it the initializeWithSuper: message, where the 
parameter is the object’s original class. This initialization 
method gives a default name to the lightweight class, creates a 
new method dictionary for it, and sets its superclass to be the 
class passed in, so that any messages not found in the 
lightweight classquote method dictionary will be looked up in 
the object’s original class. 

The solution described in the preceding paragraphs makes 
sure that messages sent to a lightweight object are first looked 
up in thp object’s lightweight class as desired. However, class 
messages will not work correctly as the solution has been pre¬ 
sented so far. For example, if aDay is a lightweight instance of 
Date, sending "aDay class nameOfDay: 1" should be the same as 
sending "Date nameOfDay: 1," but aDay’s class is an instance of 
lightweightClass, so "aDay class nameOfDay: 1" will try (and fail) 
to find a method for the message nameOfDay: defined for 
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LightweightClass. This problem exists because classes have sev¬ 
eral roles, including roles as method repositories and as reposi¬ 
tories for shared information (in this case, the names of the 
days of the week). We want the lightweight class to play the 
first role and the object's original class to play the second, but 
Smalltalk expects one entity to play both roles. (Alan Borning 
summarizes the various roles of class and suggests an alterna¬ 
tive approach in Reference 6.) Our solution to this problem is 
to separate out the role of method repository, which we did by 
creating a new method for all objects called dispatchingClass. 
The definition of dispatchingClass in Object is the same as that 
of class—it uses a primitive to directly access the object’s class 
from the object’s memory structure. When an object is made 
lightweight, its lightweight class is stored in the memory struc¬ 
ture and thus returned as the value of dispatchingClass. In addi¬ 
tion, LightweightClass overrides the class method to be: 

class 

"self dispatchingClass superclass 

This will return the object’s original class, as desired, since 
newWithSuper: installed the original class as the lightweight 
class’s superclass. 

The LightweightClass method compile notifying :iffail: is 
needed when a method is defined in a lightweight class and is 
implemented as: 

compile: code notifying: requestor iffail: failBlock 

"Compile the argument, code, as source cade in the context of the 
receiver and install the result in the receiver's method dictionary. 

The argument requestor is to be notified if an error occurs. The 
argument code is either a string or an object that converts to a string 
or a PositionableStream on an object that converts to a string. This 
method "does* save the source code. Evaluate the failBlock if the 
compilation does not succeed." 

| methodNode selector save method oldMethod | 
save := code asString copy. 
methodNode := self compilerClass new 

compile: code 
in: self 

notifying: requestor 
iffail: failBlock. 

selector := methodNode selector, 
method := methodNode generate, 
method sourceCode: save. 

oldMethod := self compiledMethodAt: selector ifAbsent: [nil]. 
(oldMethod notNil and: [oldMethod isBreakpoint]) 
ifTrue: [oldMethod client: method] 
jffalse: [self addSelector: selector withMethod: method], 

"selector 

There are two major differences between this method and the 
compile:notifying:ifFail: method as defined in Behavior. First, 
this method saves the source code that was passed in and 
passes it along (using the sourceCode: message) to the Compiled- 
MethodWithSource that’s generated from the message send 
"methodNode generate." Also, the code checks to see whether 
the method being compiled used to have a breakpoint and, if 
so, preserves the breakpoint in the method dictionary. (This 
logic will be explained in detail in the next section.) 

The final LightweightClass method is compilerClass, which 


simply returns a new class, LightweightCompiler, to be used when 
compiling lightweight class methods. Creating a new compiler 
class sounds overly ambitious, but it’s actually quite simple, 
since the new class has only one method, newCodeStream; the 
rest are inherited straight from SmalltalkCompiler. This method 
is used to create a new CodeStream for use by the compiler. Since 
CodeStream generates CompiledMethods by default, we changed it 
to be parameterized by the kind of method generated, and so 
LightweightCompiler implements newCodeStream simply by re¬ 
turning a CodeStream that will generate instances of Compiled- 
MethodWithSource. The implementation of CompiledMethodWith- 
Source is just as simple. We changed three methods so that the 
sourceCode instance variable is interpreted as a source string 
(rather than a pointer to a file and offset), and the rest of its 
functionality is inherited from CompiledMethod. 

With these few changes we now have an easy way to change 
the behavior of individual objects. We still need a good inter¬ 
face for doing that, though, and we’ll describe our approach 
for that after first looking at breakpoints. 

BREAKPOINTS 

One of the typical things a programmer wants to do while de¬ 
bugging objects (and often in other debugging, as well) is to 
add “self halt” to a method—effectively adding a breakpoint. As 
it turns out, there’s a simple way to add an initial breakpoint 
using the same technique that we used above with Lightweight- 
Compiler and CompiledMethodWithSource; we’ll simply create a 
new class of compiled method, BreakpointMethod, and a com¬ 
piler for generating instances of it. This variety of breakpoint 
has three advantages over the “self halt” version: They are easier 
to add and remove, since it’s done by menu rather than by typ¬ 
ing; they don’t affect the various change mechanisms, so the 
change set and change log don’t include trivial changes for 
adding (and presumably later removing) a halt in a method; 
and they are invisible in source code, so a programmer who is 
browsing or debugging a breakpointed method will see only the 
normally defined code—the breakpoint is invisible. The one 
disadvantage of our technique is that you can halt only at the 
start of a method, though our design may be adaptable to cover 
breakpoints throughout a method’s body. 

BreakpointMethod is a subclass of CompiledMethod with one 
instance variable, clientMethod. In addition, we added a new in¬ 
stance variable, agent, to CompiledMethod. When a breakpoint 
is set on an existing CompiledMethod, a new BreakpointMethod is 
created, and these two instance variables are changed so that 
the BreakpointMethod’s clientMethod is the CompiledMethod, and 
the CompiledMethod’s agent is the BreakpointMethod. The body 
of a BreakpointMethod is always the same: It’s the expression 
"Notifier handleBreakpoint." Thus, when a BreakpointMethod is 
executed, this expression is evaluated, and Notifier responds by 
updating its stack, replacing the BreakpointMethod with its 
client—the original CompiledMethod—and opening a debugger 
with that method in the top context. In this way, the Break- 

continued on page 24... 
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Object Transition 
by Design 



Object Technology Potential 

Object Technology can provide a 
company with significant benefits: 

• Quality Software 

• Rapid Development 

• Reusable Code 

• Model Business Rules 

But the transition is a process that 
must be designed for success. 

Transition Solution 

Since 1985, Knowledge Systems 
Corporation (KSC) has helped 
hundreds of companies such as 
AMS, First Union, Hewlett-Packard, 
IBM, Northern Telecom, Southern 
California Edison and Texas Instru¬ 
ments to successfully transition to 
Object Technology. 


KSC Transition Services 

KSC offers a complete training 
curriculum and expert consulting 
services. Our multi-step program is 
designed to allow a client to ulti¬ 
mately attain self-sufficiency and 
produce deliverable solutions. KSC 
accelerates group learning and 
development. The learning curve is 
measured in weeks rather than 
months. The process includes: 

• Introductory to Advanced 

Programming in Smalltalk 

• STAP™ (Smalltalk Apprentice 
Program) Project Focus at KSC 

• OO Analysis and Design 

• Mentoring: Process Support 


KSC Development Environment 

KSC provides an integrated applica¬ 
tion development environment 
consisting of "Best of Breed" third 
party tools and KSC value-added 
software. Together KSC tools and 
services empower development 
teams to build object-oriented 
applications for a client-server 
environment. 

Design your Transition 

Begin your successful "Object 
Transition by Design" For more 
information on KSC's products and 
services, call us at 919-481-4000 
today. Ask for a FREE copy of KSC's 
informative management report: 
Software Assets by Design. 



Knowledge Systems Corporation 

OBJECT TRANSITION BY DESIGN 


© 1992 Knowledge Systems Corporation. 


114 MacKenan Dr. 
Cary, NC 27511 
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Applications of 
Smalltalk in 
scientific and 
engineering 
computation 


Richard L. Peskin 

1992 marked Smalltalk’s 20th anniversary. While using 
Smalltalk for simulation was an important goal for the environ¬ 
ment, applications to “real” scientific and engineering simula¬ 
tion and modeling have been few. In earlier Smalltalk systems, 
slow (and expensive) hardware together with slow interpreters 
were adequate reasons for the scientific community to ignore 
Smalltalk. Addiction to FORTRAN and conservatism com¬ 
pounded the problem. 

Today’s modern Smalltalk systems running on high perfor¬ 
mance workstations have removed some of the traditional barri¬ 
ers to the use of the language for scientific computing. While in¬ 
terpretive environments are generally an order of magnitude 
slower than optimized compiled code for numerically intensive 
tasks, techniques to integrate compiled code segments into 
Smalltalk applications can overcome this deficit. The advantages 
of Smalltalk's graphical interface and its ability to promote pro¬ 
totyping offer much for scientific computing. 

To address the issues and problems presented by scientific 
applications of Smalltalk, Kent Beck of First Class Software and 
I organized a workshop at OOPSLA ‘92 in Vancouver. Atten¬ 
dance was by invitation only. Ten position papers were pre¬ 
sented during the morning session, the afternoon session was 
devoted to informal workgroups that delved into design and 
implementation specifics. The position papers covered a wide 
range of domain-specific topics concerned with applying 
Smalltalk to scientific and engineering computation. However, 
all the papers were characterized by certain commonalities, one 
of these being that Smalltalk’s flexibility does admit strategies to 
overcome weaknesses such as computational performance. I 
opened the meeting with some overview comments and noted 
the rising interest in object-oriented computing within the sci¬ 
entific and engineering community. Furthermore, with the 
rapid increase in hardware performance, we can expect more 
applications of interpretive environments to scientific and en¬ 
gineering problems. This is already evident in journal articles 


where languages like Lisp, Prolog, Smalltalk, etc. are taking 
place alongside FORTRAN and C. However, this domain com¬ 
munity is very demanding; if existing 0-0 environments are 
not suitable, users will create ones that are. Sather is an exam¬ 
ple. 

I also emphasized the need for robustness, completeness, 
and correctness in Smalltalk implementations if they are to 
meet the needs of the scientific community. Support for exter¬ 
nal programs, inter-application communication, distributed 
and parallel computation, and numerical and symbolic com¬ 
putation classes are just some of the features needed, but are 
currently either absent or minimally present in Smalltalk sys¬ 
tems. This level of support may be a tall order for a language 
with only one or two vendors and no “standard”; one reason 
for the popularity of Lisp among the scientific community is its 
standards and its multi-vendor support. 

The bottom line is that the scientific and engineering com¬ 
putation community will adopt 0-0 systems and do want the 
prototyping flexibility offered by an interpretive environment 
with dynamic binding. If Smalltalk is to be chosen by more 
than just a token few, its user community and vendors will 
have to work together to meet the needs of scientists and engi¬ 
neers. The OOPSLA workshop was set up to be one forum to 
assist in this process. To this end, vendor representatives were 
invited to attend, and ParcPlace Systems had a representative 
at the workshop. The morning presentations were further di¬ 
vided into general topics (mathematics, engineering computa¬ 
tion, scientific computation, and scientific data management) 
and application papers. However, these boundaries were not 
sharp. Professor David Rector of the University of California, 
Irvine opened the morning session with a discussion of his 
work in the development of a Smalltalk-based system to teach 
numerical analysis to students. He presented several examples 
of how current Smalltalk standard implementations fail to pro¬ 
vide needed support. One example is the absence of precise in¬ 
terval subdivision (which he has corrected). He suggested im¬ 
plementing a new iterator, map: [aBlock], so that collection 
operations return correctly (e.g., so that collect: over a dictio- 
naiy returns a dictionary, etc.), and he showed how this applies 
to a differential equation solver method- Rector suggested a 
separate class, Quantity, under Object, because Number is not ap¬ 
propriate to hold integral domains and fields such as complex 
numbers, polynomials, quaternions, etc. He also pointed out 
that class Array is not the proper container for Vectors and Ma¬ 
trices. In particular, the many varieties of matrices implies the 
need for a more general class to deal with these objects. This 
subject became the topic of one of the afternoon working 
groups. 

Alan Knight, formerly of the Department of Mechanical 
and Aerospace Engineering at Carleton University, presented 
an overview (co-authored with N. Dai) of Smalltalk in the con¬ 
texts of applications to finite element method solvers. Drawing 
on five years of experience in attempting to use Smalltalk for 
this type of problem, he listed the major problem areas of per¬ 
formance, portability, graphics, and user-interface facilities. 
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Approaches to performance improvement include use of prim¬ 
itives and high-performance libraries, and improved imple¬ 
mentations. Knight pointed out that Smalltalk’s claimed high 
portability falls short of the mark in practice, both in portabil¬ 
ity between versions and limited number of supported plat¬ 
forms. Smalltalk’s integration with other languages needs to be 
improved, as do graphics (particularly 3-D graphics) for sci¬ 
entific and engineering applications. The integration and 
graphics issues were also discussed in other papers at the work¬ 
shop. Weaknesses in the user interface, particularly the need 
for good widget toolkits was mentioned, and he emphasized 
the need for significant improvements in the debugger. 

Dr. Rob Gayvert of RIT Research Corp. discussed the use of 
Smalltalk in scientific computations, with emphasis on appli¬ 
cations in speech and signal processing. He also emphasized 
the need for improvement in the numeric array and matrix 
classes, listing specific new protocols for both numeric array 
and matrix classes. His group has implemented these in 
Smalltalk/V Mac. His suggested strategy for domain-specific 
classes (such as may arise in nonlinear equation solvers) is to 
implement first without regard to performance and then to 
optimize. The RIT group has implemented inter-application 
communication (specifically AppleEvents) as well as exten¬ 
sions to the ToolBox access in Smalltalk/V Mac. This gready 
increases the potential for access to external data sources, ap¬ 
plication servers, etc. This should be a standard feature in fu¬ 
ture Smalltalk releases. Gayvert showed examples of his system 
improvements, namely the speech processing application. Bet¬ 
ter numeric and matrix classes, IAC, etc. allowed the construc¬ 
tion of tools to do speech processing, which have both algo¬ 
rithmic power and good graphical presentation for the user. 

His conclusion is that, with proper additions and improve¬ 
ments, Smalltalk has strong potential for scientific and engi¬ 
neering applications. 

Dr. Sandra Walther of Rutgers, in a paper I co-authored, 
reviewed some features of the Smalltalk-based SCENE system, 
a software environment to support numerical experimentation 
in science and engineering. Some features of importance in 
this environment include user extensibility and configurability, 
automatic programming, computational steering, distributed 
storage, and parallel/distributed processing. The talk focussed 
on the strategies used to handle very large data sets—sets so 
large that their representation in Smalltalk as data objects is 
impractical. The large data sets were implemented as active 
processes running on a (server) platform. In this way, one can 
handle these sets efficiently, but to users of the Smalltalk inter¬ 
face the sets appear as manipulatable objects. Practical use of 
this scheme requires some good interprocess communications, 
and a means for users to tailor particular data sets to meet their 
needs. The latter facility is provided by an object editor tool that 
is used to create and compile new C code for the active data set 
and tailor menus and other interface items in response to user 
directives. 

In conclusion, Smalltalk can be appended to handle large 
data sets and other scientific computational requirements. 
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■ Scientific and engineering computation 


These facilities provide Smalltalk-like incremental compilation 
and dynamic binding features outside of the actual Smalltalk 
environment. 

The portion of the workshop devoted to applications be¬ 
gan with a talk by Jan Steinman of Bytesmiths. He described 
his work in using Smalltalk to develop laboratory instrumen¬ 
tation interfaces. He introduced the concept of the "abstract” 
instrument object (instances of an InstrumentObject class), 
which allow standard abstractions of physical instruments and 
effects a basis for common data acquisition protocols. Other 
features, such as appropriate abstract protocols, were also dis¬ 
cussed. As an example he described the Tektronix instrument 
ensemble control system, a stack-based machine architecture 
for controlling instruments and returning results via a graphi¬ 
cal interface. This was developed under the object paradigm in 
Smalltalk. The position paper by P. Johnson and D. Herkimer 
of Martin Marietta was not presented, but copies were avail¬ 
able. The paper describes a space vehicle launch simulator 
written in Smalltalk/V Mac. Among the issues discussed were 
the need for support for parallel computation abstractions in 
Smalltalk that would provide a framework for implementa¬ 
tion of parallel computation of numerically intensive portions 
of these complex simulations. This paper also pointed out the 
need for better numerical classes in Smalltalk. Brian Remdeios 
of BC Research presented a Smalltalk application designed to 
simulate control functions for an IC engine. The hierarchical 
nature of class structure allows encapsulation of various en¬ 
gine component parts into a single functional representation 
or the ability to study individual components. In this applica¬ 
tion, Smalltalk was able to facilitate inter-object communica¬ 
tion, but it was suggested that a class to handle more general 
transfer functions between objects would be helpful. The pa¬ 
per discussed how Smalltalk models of this type could be used 
to implement non-brittle (e.g., fuzzy logic) decision process 
simulations. 

David Jones of Prior Data Science presented a paper on al¬ 
gorithm objects. While the specific application discussed was 
taken from the domain of geometric models, this paper pre¬ 
sented a controversial proposal, namely, to collect algorithms 
(methods) under a single class (Class Algorithm). This is a radi¬ 
cal departure from current Smalltalk practice where algorith¬ 
mic methods are associated with specific class behaviors. Un¬ 
der the Class Algorithm proposal, algorithms together with the 
their documentation etc. would be found in a single class, sup¬ 
ported by its own browser and other interface features. Users 
would have a single point of reference for all algorithms, and 
class behaviors would be implemented via dispatch from Class 
Algorithm. This proposal was the subject of one of the after¬ 
noon working groups. 

Judith Cushing of the Oregon Graduate Institute dis¬ 
cussed the subject of computational proxies. The difficult is¬ 
sue here is how to render results computed by different sci¬ 
entific programs comparable. The emphasis in this paper was 
on the computational chemistry domain, but the central is¬ 
sue of how to design object-oriented databases that can cap- 


Modern Smalltalk systems running on 
high performance workstations have 
removed some of the traditional barriers 
to the use of the language for scientific 
computing. 


ture both syntactic and architectural complexity associated 
with the output of various scientific computational systems 
all of which produce data relevant for a given domain exper¬ 
iment or simulation. Implementation approaches in C++ 
were discussed, and these were related to possible Smalltalk 
implementations. 

The final paper in the first session of the workshop was pre¬ 
sented by Annick Fron of DEC European Technical Center in 
France. She described an interesting application of Smalltalk to 
the simulation of an MIMD embedded computer system. The 
simulation relied on processes and monitors. The result is a 
tool that has been used for embedded signal processing appli¬ 
cations. This type of tool is very useful in design and debug 
stages and can ease problems associated with integration on 
final target architectures. 

The afternoon sessions were devoted to in-depth considera¬ 
tions of topics that arose during the presentations. Informal 
groups examined issues such as the need for better mathemati¬ 
cal algorithms and better organizations for algorithms, inter¬ 
facing Smalltalk to parallel and distributed computing, and 
mechanisms for handling scientific data in Smalltalk environ¬ 
ments. Suggestions from these sessions included the need to 
re-examine algorithms and algorithm classes, the need for bet¬ 
ter integration of Smalltalk into scientific computing environ¬ 
ments, the need for better class support for parallel and dis¬ 
tributed computing interfaces, etc. One important conclusion 
of the workshop was that this event should be repeated, per¬ 
haps on a regular basis. There was a general feeling that the sci¬ 
entific and engineering community was ready for Smalltalk. 
The critical question is whether Smalltalk is ready for that 
community. IB 


Richard L. Peskin is Professor of Mechanical and Aerospace Engi¬ 
neering at Rutgers University where he is director of the CAIP Center 
Computational Engineering Systems Lab. He has been involved with 
engineering and scientific aspects of Smalltalk since 1984. He is one of 
the designers of the SCENE (Scientific Computation Environment for 
Numerical Experimentation) system, a Smalltalk-based distributed 
computing environment that implements computational steering 
tools such as interactive scientific graphics and data management, 
automatic equation solvers, and mathematical expert systems. He 
can be reached via email atpeskin@caip.rutgers.edu. 
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HE BEST OF comp.lang.smalltalk 


Alan Knight 


Good code, bad hacks 


T here have been many attempts to define the elements 
of Smalltalk style. Some of them even agree with each 
other. Almost all of them share a common point of 
view, that of a programmer striving to write good code, Honna 
Segel (honna@bnr.ca), on the other hand, approaches the 
problem as someone evaluating a Smalltalk program, trying to 
recognize bad code: 

I’m in the curious position of evaluating a prototype writ¬ 
ten in Smalltalk without prior knowledge of Smalltalk. I 
could distinguish a terrible hack from good work in C— 
what do I look for in Smalltalk? What’s a prime symptom 
of work that will be scary to modify and extend? 

THE BASICS 

Dan Benson (benson@siemens.siemens.com) writes: 

As a first pass. I’d look at the class hierarchy. See if the 
names of the classes match the concepts intended for the 
prototype. For instance, if the prototype is supposed to be 
an airline reservation system you might expect to find 
classes representing Tickets, Airlines, Reservations, Airports, 
and so on. If the class names are way off the mark, I would 
be a bit skeptical. Next, see if there are any class comments 
to see whether the programmer was conscientious or at 
least considered that someone else might read the code. 

Some of the other things you can look for without getting 
into actual code are the organization of the class hierarchy 
(to see if it makes sense intuitively), the method categories 
(to see how well the various tasks were separated), and, per¬ 
haps, the number of instance variables and the names used 
(there shouldn’t be too many instance variables per class, 
and the names should be intuitive or at least informative). 

The most obvious thing to check, of course, is the opera¬ 
tion of the prototype itself. How well does it do what it’s 
supposed to do? Are there any bugs? If so, how serious are 
they? Is it a matter of changing the interface or would it in¬ 
volve modifying the underlying model, or perhaps starting 
all over? 

There’s good advice here, and most of it can be applied by 
someone who doesn’t know Smalltalk well. Coincidentally, I’ve 
actually seen an airline reservation system written in Smalltalk 


that did not have classes representing Tickets, Airlines, Reserva¬ 
tions, or any of the other obvious domain objects. Sure enough, 
it was bad code. 

One of these remarks, however, does seem questionable to 
me. We are to check to see if the class hierarchy "makes sense 
intuitively.” That’s pretty vague, especially for someone who’s 
unfamiliar with Smalltalk. While the hierarchy should make 
sense intuitively, this suggestion needs to be defined more 
clearly. 

For myself, I would say that classes in an inheritance hierar¬ 
chy should have a clear logical relation. This relation should 
probably be expressible as either “is-a” or “is-implemented- 
like.” This is not a two-way relationship. Not all classes that 
have these relationships should be in the same inheritance tree. 

This still leaves much room for judgment, as it should, but I 
hope it helps weed out some of the worst offenders (such as 
those using the “sounds-like” or “was-implemented-the-same- 
day-as” relations to determine their class hierarchies). 

DOCUMENTATION 

Jack Woehr (jax@well.sf.ca.us) has a simple recipe: 

Good Smalltalk comes accompanied by good documenta¬ 
tion, a separate document explaining the author’s intent, 

and probably by a glossary of objects and their methods. 

Bad Smalltalk comes without such documentation. 

Strictly speaking, the quality of the documentation and the 
quality of the code should be independent. If you take away the 
documentation, the quality of the code remains the same. All 
of us have written good code that we never quite got around to 
documenting properly. 

Practically speaking, however, good code and good docu¬ 
mentation are inseparable. This is especially true for code that 
tries to be reusable (and these days, we’re all writing reusable 
code). When I intend to use a class, the first thing I do is look 
for the class comment. All too often, the second thing I do is 
curse the author for not providing one. 

ParcPlace, to its credit, provides comments for all of its sys¬ 
tem classes. Digitalk doesn’t support class comments directly, 
but it’s easy to establish a convention for class methods con¬ 
taining comments. 
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OTHER CRITERIA 

Frerk Meyer (frerk@tk.telematik.informatik.uni-karlsruhe.de) 
provides a whole list of criteria. His suggestions are somewhat 
more difficult for novices to apply and subject to some excep¬ 
tions. I’ll discuss them one at a time. 

Use Global Variables Sparingly 

Bad—the use of global variables 

This is pretty standard, even for non-O-O programming. 
Globals have their uses, but they definitely should not be used 
to excess because they introduce extra dependencies between 
classes and generally pollute the namespace. 

Separate Domain and Interface 

Bad—instance variables in the model holding view, con¬ 
troller, or window information 

This is ParcPlace-specific, but the underlying idea is universal. 
The domain model should not concern itself with the way in 
which the interface presents information. While this is very 
important, it is something that may be difficult for Smalltalk 
novices to judge and difficult for Smalltalk programmers to do 
well. 

The simplest method of checking for this separation is to 
examine the instance variables and methods of the domain 
model for obvious interface information. This will find some 
violations, but assumptions about the interface can leak into 
the domain model in many subtle ways. There’s always a 
temptation to introduce just a few lines of code that are 
ever-so-slightly dependent on the interface. Maybe it doesn’t 
really belong in the interface, either. Besides, it would take so 
much longer to do it properly, and we’re not likely to change 
that part of the interface.... These temptations should be 
resisted. 

Greg Hendley and Eric Smith discussed these issues in some 
detail in a two-part article titled “Separating the GUI from the 
application” (The Smalltalk Report, May 1992 and October 
1992). They advocate introducing a “control” layer into the in¬ 
terface that acts as a buffer between the interface visuals and 
the domain model. 

Avoid Long Methods 

Bad—methods that are larger than one screen (usually) 

It’s pretty much a consensus that Smalltalk methods should be 
short. Long methods are probably trying to do more than one 
thing and should be broken up into their components. Long 
methods aren’t always bad, but the presence of large numbers 
is a definite danger sign. 

A notable exception is for automatically generated meth¬ 
ods, such as WindowBuilder’s horrendously long open meth¬ 
ods. But since these methods are not intended to be modified 
by humans, this is not so much of a problem. 

I notice that Digitalk’s compiler is much slower for long 


methods. This can, however, be considered a feature (though I 
doubt it was intended as one) since it motivates programmers 
to break up their code into smaller components. 

Avoid System Changes 

Bad—making changes to system classes instead of sub¬ 
classing 

After some discussion, the consensus on this point was that 
adding methods to system classes is fine, but modifying exist¬ 
ing methods is to be avoided. System changes are a problem 
because your changes are likely to be incompatible with others, 
including those in the next Smalltalk version. They’re also 
more likely to make your system crash during development. If 
you have to modify a system method, it’s usually best to make 
the modification as small as possible. Ideally, you should just 
insert a hook that calls your own code. 

Keep Instance Creation Simple 

Bad—using class method new more than A super new 
initialize 

It’s common practice in Smalltalk to override the method new 
to automatically initialize instances of the class, changing the 
code to: 

new 

A super new initialize 

Other common changes are to override new to be an error or 
to return an already existing instance. Adding much more 
functionality than this to the method is considered bad form. 
Again, it’s better to provide a hook to more extensive code in a 
method like initialize. 

Use System Classes 

Good—using system classes wherever possible 

If code that serves a purpose is already available, it should be 
reused. As an extreme example, code that uses fixed-size ar¬ 
rays, but goes through complex manipulations to mimic the 
behavior of OrderedCollection would be bad. Similarly, code 
that avoids the normal user interface mechanisms and gets 
mouse or keyboard input directly is probably bad. It may be 
trying to do something that is not normally possible through 
those mechanisms, but even then it is preferable to extend the 
UI mechanisms rather than go around them. 

Work within the System 

Good—using MVC, dependency mechanisms, and processes 

Again, if the mechanisms are there, it’s best to work with them 
rather than against them. They can, however, be overused. 

Kent Beck writes, in “Abstract Control Idioms” (The 
Smalltalk Report, July/August 1992), about the advantages 
and disadvantages of the dependency mechanism. 
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He summarizes the disadvantages as “debugging and per¬ 
formance.” Dependency-based code can be much more 
difficult to follow and debug than normal code. When it’s put 
together properly, it will often work immediately. When it 
doesn’t, tracking down the problem can be painful. 

I wouldn’t consider processes to be a necessary feature of 
good code. Multi-threaded code introduces many complica¬ 
tions, and I avoid it unless I really need it. 

Choose Names Carefully 

Good—using expressive naming of classes, methods and 
variables, and using the class document feature 

Definitely. Naming things properly is very important. One of 
my biggest complaints about both Digitalk and ENVY/Devel- 
oper is how difficult they make it to change class names. 

PUT CODE IN THE RIGHT PLACE 

Charles Lloyd (clloyd@gleap.jpunix.com) adds several points. 

Place Code Well 

A series of messages sent to some object other than self is 
probably badly placed code. That series should be moved 
to the class of the receiver. 

Note: This is the hardest thing to do well in 0-0 program¬ 
ming, but it pays very high dividends when done well. 

Breaking up methods in this way has several advantages. As 
we’ve already mentioned, it's good practice to break up long 
methods into logically connected units. A series of messages to 
some other object makes a good candidate for such a division. 
Since they have an object in common, they should probably be 
moved to a method in its class. This also provides an opportu¬ 
nity to use polymorphism (i.e., providing different implemen¬ 
tations of the same function in other classes). 

Avoid Checking Types Explicitly 
Encoding type information 

You should never see any checks for “type” information. 
All type information should be implicit in the class of the 
receiver. Exceptions to this rule are few and far between. 

It’s usually bad style to ask the type of an object. Frequent use 
of class tests or isKindOf: is a characteristic of poor code. 

Ideally, rather than testing the type, code should request 
that an object carry out some action. The object is then re¬ 
sponsible for doing the appropriate thing based on its type, but 
this is done through the method dispatch mechanism, rather 
than explicitly in code. 

If it's necessary to determine some characteristic of the ob¬ 
ject, it’s better to do so by sending a message asking about the 
characteristic. Thus, it’s better to say: 
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anObject isCollection lfTrue: [... ] 
than 

(anObject isKindOf: Collection) ifTiue: [... ] 

The second form confuses an attribute of the object (whether it 
responds to basic collection protocol) with the class hierarchy 
(whether it inherits from the class Collection). 

As a concrete example of how this can be dangerous, con¬ 
sider a system that works with vectors. We may wish to treat 
instances of Point as two-dimensional vectors. Code that sends 
the message isVector will work fine for points. Code that relies 
on isKindOf: Vector will fail. 

Put Conditional Behavior in Subclasses 
Introduction of instance variables 

Instance variables should be added sparingly. If you think 
you need N instance variables to model your subclass, 
consider introducing M subclasses (Mvery close to N) 
where each new subclass introduces a minimum of new 
variables. 

Introducing subclasses where other languages might use enu¬ 
merated “type” variables is often good style. It is a problem if 
instances may change their type, but, otherwise, it can be very 
useful. In many ways, it’s similar to the previous point. Instead 
of having conditional statements on the enumeration, we sim- 
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ply ask instances to perform some function. They will auto¬ 
matically do it in the appropriate way, and the language mech¬ 
anisms will do the testing for free. 

FAILURE MODES 

We can also look at bad code by considering how it might have 
gotten to be bad. Maybe the author didn’t understand 
Smalltalk or OOP fully. Maybe it was a quick hack by someone 
capable of doing better work. Maybe it was written by some¬ 
one who didn’t understand the domain and/or requirements. 
Maybe it really was written by an idiot. Maybe it was once 
good code that’s had too many patches and has never been 
consolidated. 

Most of these problems can be recognized the same way 
they would be in any programming language, and only a few 
have OOP- or Smalltalk-specific aspects. 

Quick hacks, for example, can usually be identified by their 
shoddy documentation and comments. The comments that do 
exist are often incomprehensible notes from authors to them¬ 
selves, often of the form “fix this later.” 

It’s usually easy to tell when the author didn’t understand 
the paradigm and wrote FORTRAN, C, or COBOL with 
Smalltalk syntax. There is often excessive use of type informa¬ 
tion (as described above), internal representations are almost 
always exported, and collections with encoded meanings are 
often used as data structures. 

The most common symptom of exporting too much repre¬ 
sentation is the presence of direct get/set methods for every 
variable in a class. Some schools of thought hold that all vari¬ 
able references should be made through get/set methods. In 
this case, the code will have such methods, but many of them 
should be clearly marked as private. 

Programmers who aren’t used to opaque data types will 
often use collections as data structures. For example, they 
might represent a circle by an array whose first element is the 
centre point and whose second is the radius, instead of intro¬ 
ducing a new class Circle. Juanita Ewing discusses this common 
error in “Don’t use Arrays?” (The Smalltalk Report, May 
1993). B 

CONCLUSION 

Although it’s far from complete, I hope this brief overview 
provides some help to those of you trying to distinguish good 
Smalltalk from bad Smalltalk. If you’re writing code, this col¬ 
umn should provide some things to strive for or avoid. 


Alan Knight works for The Object People, 509-885 Meadowlands 
Dr., Ottawa, Ontario, K2C 3N2. He can be reached at 613.225.8812 
or as knight@mrco.carleton.ca. 
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IDIOMS 


Inheritance: the rest 
of the story 


Kent Beck 


O f the three tenets of objects—encapsulation, polymor¬ 
phism, and inheritance—inheritance generates by far 
the most controversy. Is it for categorizing analysis 
objects? Is it for defining common protocols (sets of mes¬ 
sages)? Is it for sharing implementation? Is it really the com¬ 
puted goto of the nineties? 

The answer is Yes. Inheritance can (and does) do all of the 
above at different times. The problem comes when you have a 
single-inheritance system like Smalltalk. You get one opportu¬ 
nity to use inheritance. If you use it in a way that doesn't help 
you, you have wasted one of the most powerful facilities of the 
language. On the other hand, if you use it poorly, you can mix 
up the most ridiculous, unmaintainable program gumbo 
you’ve ever seen. How can you walk between the rocks of un¬ 
der-using inheritance and the chasm of using it wrongly? 

What’s the big deal? Inheritance is the least important of 
the three facilities that make up objects. You can do valuable, 
interesting object-oriented programming without using inheri¬ 
tance at all. Programmers still quest after the Holy Grail of in¬ 
heritance because of the potential it shows when it works well. 
When you need an object and find one that is factored well 
and does almost what you want, there are few experiences in 
programming better than making a subclass and having a 
working system after writing two or three methods. 

In this and my next several columns, I will focus on various 
aspects of inheritance. I will present a variety of strategies for 
taking advantage of inheritance, in the form of patterns. While 
I don’t necessarily use all the patterns in my own program¬ 
ming, casting the strategies in terms of patterns makes it easier 
to compare and contrast them. 

PATTERN: COMPOSE METHODS 

This pattern is the cornerstone of writing objects that can be 
reused through inheritance. It is also critical for writing objects 
that you can successfully performance tune. Finally, by forcing 
you to reveal your intentions through method names, it makes 
your programs more readable and maintainable. 

Context 

You have some code that behaves correctly (it does no good to 
beautify code that doesn't work, unless you have to make it 
work). You go to subclass it, and realize that to override a 
method you have to textually copy it into the subclass and 


change a few lines, forcing you forever after to change both 
methods. 

Another good context for this pattern is when you are look¬ 
ing at a profile that looks flat; that is, no single method stands 
out as taking more time than others. You need further im¬ 
provement in performance and believe that the object can de¬ 
liver it. 

Problem 

How can you write methods that are easy to override, easy to 
profile, and easy to understand? 

Constraints 

Fewer, larger methods make control flow easy to follow. Lots 
of little methods make it hard to understand where any work is 
getting done. Lots of little methods named by what they are in¬ 
tended to do, not how they do it, make understanding the 
high-level structure of a computation easy. Your programming 
time is limited. You only want to perform manipulations of the 
code that will have some payoff down the road. Each message 
sent costs time, and execution time is limited. You only want 
to cost yourself execution time if the result will provide some 
advantage at some point. You don’t want to introduce defects 
in working code. The manipulations must be simple and me¬ 
chanical to avoid errors as much as possible. 

Solution 

Make each method do one nameable thing. If a method does 
several things, separate out one of them, create a method for it, 
and invoke it in the original method. When you do this, make 
sure that if the same few lines occur in other methods, those 
methods are modified to invoke the new one as well. 

This solution ignores the cost of message sending. You will 
get faster programs by using messages to structure your code 
so that you can more easily tune them than by reducing the 
number of messages. It also assumes that the eventual reader of 
the code is comfortable piecing together control as it flows 
through lots of small methods. 

Example 

A method for parsing a stream to eliminate lines that begin 
with a pound sign might look like this at first: 
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parse: aStream 
| writer | 

writer := String new writeStream, 

[aStream atEnd] whileFalse: 

[(aStream peekPor: $#) 

ifTrue: [aStream restOfLine] 

ifFalse: [writer nextPutAU: aStream restOfLine]] 

Applying "Compose Methods" to parse: to separate line parsing 
from the overall parsing control structure we get: 

parse: aStream 
| writer | 

writer := String new writeStream. 

[aStream atEnd] whileFalse: 

[self parseLine: aStream onto: writer] 

parseline: inStream onto: outStream 
(aStream peekFor: $#) 

ifTrue: ["aStream restOfLine]. 
outStream nextPutAU: aStream restOfLine 

Notice that by creating parseIine:onto: we are now able to use the 
return control structure to make the submethod easier to extend. 
Applying it again to factor out the outputStream creation, we get: 

parse: aStream 
| writer | 

writer := self outputStream. 

[aStream atEnd] whileFalse: 

[self parseLine: aStream onto: writer] 

outputStream 

"String new writeStream 

Applying it to parseline:onto: to separate the choice of what is a 
comment from the behavior when a comment is found we get: 

parseLine: inStream onto: outStream 
(self peekForComment: inStream) 
ifTrue: [inStream restOfLine]. 
outStream nextPutAU: inStream restOfLine 

peekForComment: aStream 
"aStream peekFor: t# 

Apply it to peekForComment: to separate the character you are 
looking for from the way in which you look for it: 

peekForComment: aStream 

"aStream peekFor: self commentCharacter 

commentCharacter 

"J# 

The final code is much easier to modify in a subclass if you 
want to change the comment character, write onto something 
other than a string, or extend the parsing to deal with special 
cases other than comments. 

PATTERN: SEPARATE ABSTRACT FROM CONCRETE 

This is a pattern I learned from Ken Auer of Knowledge Sys¬ 
tems Corporation. He told me about using it to great advantage 


in a financial services application in which there were many 
kinds of financial instruments, all implemented similarly. 


By understanding the options and 
trade-offs involved, you can use it to 
your advantage. 99 


Context 

You have implemented one object. It has some methods that 
rely on the values of variables, and others that do not. You can 
see that you will have to implement many other similar objects 
in the future. 

Problem 

How can you create an abstract class that will correctly capture 
the invariant part of the implementation of a family of objects 
with only one concrete example? 

Constraints 

You want to begin using inheritance as early as possible to speed 
subsequent development, and you want you inheritance choices 
to be correct so you don’t have to spend time refactoring later. 

Solution 

Create a state-less superclass. Make it the superclass of the class 
you want to generalize. Put all of the methods in the subclass 
which don’t use variables (directly or through accessors) into 
the superclass. Leave methods that rely on instance state in the 
subclass. 

This solution strikes a balance between inheriting too early 
and too late. By making sure you have one working class you 
know you aren’t using inheritance entirely on speculation. 

Example 

Let’s say that we have an RGBColor represented as red, green, and 
blue values between 0 and 1. We can then write methods like: 

hue 

"Complicated code involving the instance variables red, green, and 
blue...” 
saturation 

"Complicated code involving the instance variables red, green, and 
blue...” 
value 

"Complicated code involving the instance variables red, green, and 
blue..." 
complement 
"self species 

hue: (self hue + 0.5) fractionalPart 
saturation: self saturation 
value: self value 
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Applying “Separate Abstract from Concrete” to RGBColor, we 
create Color as RGBColor’s superclass. We move complement to 
Color, because it doesn’t rely on any instance variables directly. 
We leave hue, saturation, and value in RGBColor because they 
do rely on variables. 

Now, if we want to create Color subclasses that store color 
values in other ways, they can inherit complement as long as 
they implement hue, saturation, and value. 

When you apply this pattern, you will often find that meth¬ 
ods which were implemented initially as requiring variable val¬ 
ues can be recast by applying “Compose Methods” so they can 
be moved into the superclass. 

CONCLUSION 

Now that I have written down Separate Abstract from Concrete, 
I’m not sure I entirely agree with it. I like to have more than 
one concrete example before I try to generalize. I use two 
different patterns, “Factor Several Classes” and “Concrete Su¬ 
perclass” in my own programming. I will present these pat¬ 
terns in the next issue. 

Inheritance is strong medicine. Only by understanding the 
options and trade-offs involved can you avoid the pitfalls and 
use it to your advantage. If you use different patterns for apply¬ 
ing inheritance, please send them to me. fl 

Kent Beck is founder of First Class Software. He can be reached at 
408.338.4649 (v), 408.338.3666 (f), or via CompuServe at 
70761,1216. 
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■ Smalltalk debugging techniques 


the method. Data you write to the Transcript should be 
identified, and should include some formatting such as tabs 
and carriage returns. Here is an example of an expression that 
would be inserted in the method of a class that understood the 
total message: 

Transcript cr; show: Total =' ,self total printstring. 

This expression prints the string Total =' concatenated with the 
string result of sending the total message to the receiver. The 
comma in the above expression is a message that returns the 
receiver concatenated with the argument, another string. Use it 
when you want to append a string. In this example, the result 
of the total message is an integer, so piintString is used to ob¬ 
tain the string equivalent. 

Use a global variable to control printing information to the 
Transcript, setting it to true or false from a workspace when 
you want to turn printing on or off. In this expression we use a 
global named Debug: 

Debug ifTme: [Transcript cr; showr'starting calculations...'] 

Instead of setting the global to a boolean, you can set the global 
to an integer that controls how much detail you print: 

Debug > 4 ifTrue: [Transcript show:"detailed information'] 

In Objectworks, you’re not restricted to a single Transcript. If 
you would like to create customized transcripts to separate 
different types of messages, refer to the Creating a transcript win¬ 
dow section on creating transcript windows in Chapter 21, “Text 
and text views,” in the Objectworks Smalltalk User’s Guide. 

Menu Hooks for Inspectors 

Printing a lot of information out to the Transcript can get 
rather tiresome. An attractive alternative is to open an inspec¬ 
tor on key objects at strategic points in the code or, better yet, 
to provide an easy way for the developer to access an inspector. 
When you are creating new window applications, it’s handy to 
include an inspect item in the window’s menu during the ini¬ 
tial development phase. This is a quick and easy way access the 
objects behind the window. 

Inspect is implemented by Object, so you don’t have to pro¬ 
vide a new method if you’re happy bringing up an inspector on 
the object that accepts responsibility for menu messages. If you 
do need to customize the inspect action from a window, pro¬ 
vide a new message rather than overriding the inspect message. 
If you override inspect, your customized method, instead of the 
inherited method, will be executed by the system whenever the 
inspect message is sent to the object. Opening an inspector 
from an inspector, for example, uses the inspect message. If 
you want to inspect the selected item in a list directly from a 
menu, implement a new message called inspectSelectedltem 
and avoid overriding inspect. 

Object identity 

Situations arise in which you need to compare two variables to 
see if they reference the same object. For example, you might 


be stepping through two similar sets of actions that involve a 
particular object. One works and the other doesn’t, so you 
need to determine whether the two variables reference exactly 
the same object. 

Object identity is determined with the = = message, which 
answers whether the receiver and the argument are exactly the 
same object. In contrast, the = message is used to determine 
object equality: It answers whether the receiver and the argu¬ 
ment are equivalent: 

#asdf = #asdf “true: Symbols are unique.” 

'asdf == 'asdf “false: Strings are not unique." 

If the two objects are not in the same context (i.e., you have 
captured them in separate inspectors), you can assign one to a 
global variable and use the object identity message to deter¬ 
mine equality. 

GlobalOne := self name. "in one inspector" 
self name = = GlobalOne. "in a different inspector" 

Don’t forget to remove global variables when you’re through 
with them: 

Smalltalk removeKey: #GlobalOne 

Use standardized names, such as an unusual prefix, to identify 
temporary globals. 

Older Smalltalk systems supported as hash as a means of 
uniquely identifying objects. In current Smalltalk systems, nei¬ 
ther of these messages uniquely identify an object. 

Names 

It is often a good idea to add a name or id field to an object 
strictly for debugging purposes, particularly when instances 
cannot be uniquely identified by their instance variables or 
when they are distinguished in obscure ways. If you’re going to 
be dealing with multiple instances of a class, it may otherwise 
be hard to keep track of which object is which. 

You also can specialize the method printOn: for your new 
classes. The printable representation can incorporate a name to 
help identify the object. 

printOn: aStream 

"Add a printable representation of thereceiver to <aStream>. 

Use the fullName field to identify thereceiver." 
super printOn: aStream. 
aStream nextPutAll:' on '. 
aStream nextPutAll: self fullName 

A good printable representation can speed debugging, because 
it lets you quickly ascertain when two objects are equal or how 
they were created. However, be aware that assumptions in a 
specialized printOn: method might not be correct. For example, 
some instance variables might not have been initialized. If so, 
the previous method should be checked to see if the name were 
nil before printing it. 

WHERE AM I AND HOW DID I GET HERE? 

An object encapsulates both behavior and data. In addition to 
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gathering information about the data in your application, you 
may need to collect information about the dynamic state of 
your application. Two keys to understanding the dynamic state 
of your application are identifying where you are in the dy¬ 
namic sequence of message sends and identifying how you got 
there. 

We also present two alternate ways to access dynamic state: 
locating code of interest via user input and using key entry 
points. 

Identifying the Current Context 

When you need to identify the method you are executing, 
print an identification expression to the Transcript. The fol¬ 
lowing prints the class and message name as it appears in the 
debugger’s stack (e.g., Class(Superclass)»methodName).For Ob- 
jectworks: 

"if it's not in a block" 

Transcript show: thisContext printstring; a. 

Debug ifTrue: ["use this expression in a block" 

Transcript show: thisContext sender home printstring; cr]. 

For Smalltalk/V: 

CunentProcess walkbackOn: Transcript maxLevels: 1. 

Audible Feedback 

Another alternative to writing to the Transcript is to use sound 
to give audible feedback that a method has been executed. This 
is particularly useful in situations where the display system is 
not available. For example, in Smalltalk/V the GO file is pro¬ 
cessed before the display system is available. Insert these ex¬ 
pressions to ring the bell. For Objectworks: 

Screen default ringBell. 

For Smalltalk/V: 

Terminal bell. 

Catching It in the Act 

If you would like to examine code behind a specific action, but 
don’t know where to find the method, you can interrupt it by 
typing the program interrupt while executing the code of inter¬ 
est. In Objectworks, the default program interrupt is <CTRL-C>. 
In Smalltalk/V, it is the platform interrupt key (<CTRL-BRK> 
under OS/2 and Windows, <command-.> on the Mac). 

For example, if you want to know how the rubberbanding 
code works when drawing a line in a graphics editor: 

1. Perform the appropriate action, such as holding down the 
left mouse button and dragging the cursor. 

2. While you move the mouse, press the program interrupt, 

3. A notifier appears that allows you to open a debugger and 
examine code in the stack. You can see flow of control in 


the debugger, and can examine method arguments and 
temporaries. 

Timing can sometimes be a problem —for some operations 
you may need to try this several times until you catch it at the 
right place. 

Sometimes a program interrupt can save you from a bad 
situation. If you make a simple change to your code and see a 
garbage collection cursor instead of what you expect, you may 
have created an infinite loop. The following is a typical exam¬ 
ple of a class method that inadvertently causes an infinite loop: 

new 

"self new initialize'this should be a call to super instead of to self 

In this method, the user intended to invoke the inherited 
method called new, but instead called the same method, result¬ 
ing in an infinite loop. 

If your application is in an infinite loop, you can interrupt 
it with a program interrupt. After interrupting the application, 
use the debugger to look at the stack and locate the error, fix 
the error and then either close the debugger and start again, or 
resume the execution from the debugger. 

Be careful when you interrupt a method with a program in¬ 
terrupt. Instead of closing the notifier or debugger, you may 
need to resume or proceed from the debugger if you are in a 
loop that needs to finish execution to restore the state of the 
cursor, signal a semaphore, or complete some other clean-up 
activity. 

Alternative to Walkbacks and Notifiers 

You may not want to open a debugger and, instead, prefer 
some other way to view the context information. If you are de¬ 
bugging low-level code and are concerned that an interruption 
might leave the image in an unstable state, you can print out 
information about the current context as described below. It 
can also be useful if you are sending a beta release to customers 
or if you are working on an embedded application in which 
there is no access to a user interface. The following expression 
prints the execution stack on the Transcript. For Objectworks: 

Transcript cr; show: (NotifierView shortStackFor: thisContext). 

For Smalltalk/V: 

CunentProcess walkbackOn: Transcript maxLevels: 10. 

You can also print this information to a file. For Objectworks: 

| file | 

file := 'enors' asFilename appendStream. 

file cr; nextPutAll: (NotifierView shortStackFor: thisContext). 

file close 

For Smalltalk/V: 

| file | 

file := File pathName: 'enors'. 
file setToEnd. 

CunentProcess walkbackOn: file maxLevels: 50. 
file close 
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Source Code for Blocks 

Although the source code is not always available, the following 
expressions are sometimes helpful for examining the source 
code for blocks (Smalltalk/V) or BlockClosures or MethodCon- 
texts (Objectworks). For Objectworks: 

aBlockClosuie method getSource 
aMethodContext sourceCode 

For Smalltalk/V for OS/2: 

aBlock homeContext method sourcestring 

Decompiling a Method in Objectworks 

If the source code for a method is unavailable, the Objectworks 
browser allows you to view a decompiled version of the 
method: The comments are gone, certain expressions are opti¬ 
mized, and the temporary variable names tl, t2, and so on are 
used in place of the original argument and temporary variable 
names. 

Even when the source code is available, you can view the 
decompiled version of the method if you hold down the shift 
key when you select the method name in the Objectworks 
browser. This technique is useful for finding obscure bugs such 
as when literals have been unknowingly altered. Many pro¬ 
grammers think that Smalltalk literals are immutable, and do 
not realize that they can be altered. The following example il¬ 
lustrates detection of an altered literal array. 

A method initializes an instance variable to reference a lit¬ 
eral array: 

initialize 

airayConstant := #(1 2 3 4) 

The programmer intends this to be a constant, but later uses 
an expression such as the following to alter the array: 

airayConstant at: 1 put: 100 

This alters the contents of the literal array in memory, so the 
original contents of the array are not restored even if the origi¬ 
nal initialize method is re-executed. You can check the con¬ 
tents of the literal array by decompiling any method that refers 
to it. After altering the array, the decompiled contents of the 
initialize method are: 

anayConstant := #(100 2 3 4) 

If you recompile the method from the source, the original con¬ 
tents of the literal array are restored. This is a particularly nasty 
bug to locate, so be forewarned. To prevent this type of bug, 
some programmers provide accessing methods for important 
literals, and return a copy of the literal instead of the original, 
Because the original literal is never returned, inadvertent alter¬ 
ations are made only to the copy. 

Entry Points 

Sometimes you just want to know how a window is opened or 
what happens when a menu item is invoked. Instead of inter¬ 


rupting it, sometimes it’s easier to trace the action down from 
a few well-known entry points. 

For example, the Objectworks Launcher lets you open 
browsers, workspaces, and other windows. The code behind 
this master menu is found in LauncherView and VisualWorks 
UIVisualLauncher class methods. Browse all implementors of 
'*enu*' to see menu initializations for other windows: select im¬ 
plementors from the VisualWorks Launcher Browse submenu 
or the ENVY Launcher ENVY>browseimplementors... alternative. 
The string '*enu*' matches selectors such as menu and filelist- 
Menu regardless of the capitalization. 

The file menu in Smalltalk/V contains items to open 
browsers, workspaces and other windows. The class Applica- 
tionWindow supports the file menu, and contains entry points 
to tools. Browse the class to examine the methods that open 
windows. 

WHERE AM I GOING? 

This section highlights techniques that allow you to temporar¬ 
ily halt or gain more control over the execution. Some tech¬ 
niques, such as slowing down the action in your application, 
are oriented towards graphical operations. 

Breakpoints 

Although Smalltalk has a well-earned reputation for its debug¬ 
ging environment, current implementations place some re¬ 
strictions on breakpoints. In Smalltalk/V, you can set break¬ 
points from a debugger. In Objectworks, you have to 
recompile a method and insert code to stop execution. Remov¬ 
ing the code to stop execution also requires recompilation. 

In both Smalltalk systems, one of the first debugging tech¬ 
niques you learn is to send the message halt to any object. 

When executed, it prompts you to open a debugger. In a de¬ 
bugger, you can execute expressions and inspect the current 
object, its instance variables, and any method temporaries. The 
message error: also prompts you open a debugger, and uses its 
argument in the title of the walkback or notifier. These expres¬ 
sions can be inserted in a method or executed in a workspace. 

self halt. 

self enor: 'Invalid data during retrieval' 

However, you quickly learn that this needs to be used with 
caution. If you place the expression inside a loop, a notifier ap¬ 
pears each time the loop is executed. You can guard the ex¬ 
pression if you know exactly when you want to break: 

i > 10 iflrue: [self halt] 

Or you may choose to control the execution dynamically. For 
example, the following expression halts only if the shift key is 
pressed. For Objectworks: 

InputState default shiftDown ifTrue: [self halt] 

For Smalltalk/V: 

(Notifier isKeyDown: VkShift) ifTrue: [self halt] 
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If the code is being executed from a controller method in Ob- 
jectworks, you can use the simpler: 

self sensor shiftDown ifTrue: [self halt] 

If this interferes with other tests for the shift key, you can also 
test for the Meta, Option, Alt (if it isn’t commandeered by 
your windowing system), or Ctrl keys. For more information, 
see the section on sensing input near the end of Chapter 18, 
“Application framework,” of the User’s Guide for Object - 
works\Smalltalk. 

For Smalltalk/V, you can use platform-dependent keys with 
expressions such as the following. For Smalltalk/V for Win¬ 
dows, use: 

(Notifier isKeyDown: VkControl) ifTrue: [self halt] 

You can also gain control over the execution of non-primitive 
expressions executed in the context of a workspace, debugger, 
or inspector. For example, execute do it on the expression be¬ 
low, which sends the halt message to 3: 

3 halt raisedTo: 2 

In the debugger, step or skip through the messages until you get 
to the raisedTo: message and then send or hop. You can’t step 
into a primitive, such as integer addition, from the debugger. 

Slowing Down the Action 

Sometimes you don't actually want to stop the action; you just 
need to slow it down a little. For example, you’re looking at 
code that draws a complicated figure with a loop and you want 
to see each line segment drawn, one at a time. You might use a 
delay in the loop For Objectworks: 

Cursor wait showWhile: [(Delay foiMilliseconds: 800) wait] 

For Smalltalk/V for OS/2: 

CursorManager wait changeFor: [DosLibrary sleep: 800] 

In Objectworks, don’t forget to send the wait message to the 
delay. You can create an instance of a Delay anytime you like, 
but it doesn’t actually stop the action until the wait message is 
sent. 

Or, you might choose to wait until a mouse button is 
clicked For Objectworks: 

Cursor crossHair showWhile: 

[ScheduledControllers activeController sensor waitNoButton; 
waitClickButton] 

This expression waits until all mouse buttons are up and then 
waits again until one is pressed. For Smalltalk/V: 

CursorManager execute changeFor: 

[Notifier consumelnputUntil: [:event | 

event selector =#buttonlDown:]. 

Notifier consumeInputUntil:[:event | 

event selector = #buttonlUp:]] 

This expression waits until the left mouse button is pressed 
and then released. 

The first expression makes sure you aren’t in danger of run¬ 


ning on through the whole expression just because the mouse 
button was still down from a previous operation such as a 
menu invocation. 

Changing the cursor while the system is sleeping or waiting 
for a button press is a good visual reminder of your program’s 
action. There are a number of other cursors available, and if 
you have multiple delays in a method, you can use different 
ones to give you feedback about the state of the execution. 

A delay can also give you time to interrupt a method with a 
program interrupt if you so choose. 

HOW DO I GET OUT? 

One of the best things about the Smalltalk environment is that 
you can change almost anything you like. One of the worst 
things about the Smalltalk environment is that you can change 
almost anything you like. If you happen to alter your environ¬ 
ment in an undesirable way, you can also find yourself in big 
trouble. 

Although you might be able get yourself out of a tight spot 
if you have enough time, skill, and patience, you may find that 
it’s best to quit out of an image and recover desirable changes 
in a fresh image rather than to undo the damage. 

Quitting while You're Ahead 

If your normal means of exiting is blocked, you can often exit 
by evaluating an expression. In Objectworks, the magic expres¬ 
sion to gracefully shut down the image when all else has failed 
is: 

ObjectMemoiy quit 
or 

ObjectMemoiy quitPrimitive 

In pre-4.1 Objectworks, this message was sent to Smalltalk in¬ 
stead. 

In Smalltalk/V, the expression is: 

Smalltalk exit 

If your image seems dead and you don’t get any response from 
typing, first try the program interrupt and attempt the exit 
procedure again. If that doesn’t work, then, for Objectworks, 
use the Emergency Evaluator to evaluate the exit expression: 

1. Type <CTRL-SHIFT-C> to bring up the Emergency Evaluator. 

2. Type the exit expression ObjectMemoiy quit. 

3. Type <ESC> to evaluate the expression. 

In Smalltalk/V for OS/2, use the Windowlist provided by OS/2 
to remove an unwanted process: 

1. Type <CTRL-ESC> to bring up the Windowlist. 

2. Select the top-level Smalltalk/V Window or the Transcript. 

3. Bring up the menu and select Close. 

OS/2 also notices if a process is not responding to events and 
prompts you to exit the process. 

In Smalltalk/V for Windows, you can use the WindowList 
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provided by Windows to remove an unwanted task with the 
End Task button. A more reliable method is to type <CTRL-ALT- 
DEL>. The first <CTRL-ALT-DEL> allows you to exit the current 
process. Another <CTRL-ALT-DEL> allows you to reboot the 
machine. 

After exiting, use the appropriate utilities to recover the 
changes you want to keep, being careful not to restore the 
method or methods that caused the crash. 

An Advanced Emergency Procedure for Objectworks 

If you’re feeling more adventuresome and know exactly what 
you did wrong, Objectworks allows you to recompile the 
offending method instead of quitting. For example, you insert 
a self halt in a critical method such as the otherwise empty con- 
trollnitializel method and quickly realize that you should have 
done this in a subclass when you see all the notifiers pop up. 
Since <CTRL-C>, the program interrupt key, doesn’t help, you 
type <CTRL-SHIFT-t> to bring up the Emergency Evaluator and 
then evaluate the following expression to restore the original 
method: 

Controller compile: 'controllnitialize ''self classified: 

'basic control sequence' 

Don’t be concerned about making the method pretty or get¬ 
ting the protocol exactly correct; you can and should fix those 
details once your environment is back to normal again. 

OTHER DEBUGGING AIDS 

Ways to debug problems are as varied as the bugs themselves, 
but the following tips include advice about general approaches 
to object-oriented debugging, techniques for graphical debug¬ 
ging and ways to add shortcuts to access frequently used de¬ 
bugging expressions. 

Isolate Debugging Code in a Subclass 

Whenever possible, isolate your debugging code in a new sub¬ 
class. You can copy methods from the superclass or override 
them to add debugging information. This is most useful when 
you are primarily interested in finding out how the current sys¬ 
tem works and your debugging activities are confined to halts 
and monitoring activities such as printing to the Transcript. If 
you are trying to find a genuine bug and functionally changing 
code, you have to remember to copy the changes back to the 
real class. 

Graphical Feedback 

When you’re debugging graphical applications, you need a lot 
of visual feedback. If your application is interactive, you might 
need to understand where the cursor is located and how to 
manipulate it. 

In Objectworks, you can find out where the cursor is rela¬ 
tive to the window with the expression: 

ScheduledControllers activeController sensor cursorPoint 

You can position the cursor explicitly with: 


ScheduledControllers activeController sensor cursorPoint: aPoint 
You can ask the user to interactively designate an area on the 
screen: 

Rectangle fromUser 

Indicate an area with a filled rectangle: 

ScheduledControllers activeController view graphicsContext 
display Rectangle: (0@0 extent: 10(3100) 

In Smalltalk/V, there are a similar set of expressions. To find 
the location of the cursor in screen coordinates use: 

Cursor sense 

To translate to coordinates for a pane use: 

Cursor sense mapScreenToClient: aPane 
To set the location of the cursor relative to the screen origin: 
Cursor offset: aPoint 

You can ask the user to interactively designate an area on the 
screen: 

Display rectangleFromUser 

You can also indicate a screen area, in this case by filling the 
rectangle with a solid red color: 

Display pen fill: Display rectangleFromUser color: CliRed 

Magic Debugging Keys 

If you find that you use certain debugging expressions fre¬ 
quently, you can modify your programming environment to 
add these expressions with function keys or keyboard 
equivalents. 

For Objectworks, we use function keys to insert some of the 
debugging expressions mentioned previously. 

The FaragraphEditor’s initializeDispatchTable class method 
controls the binding of keys to actions. Rather than adding to 
this method, the following code creates a new method for the 
debugging bindings: 

ParagraphEditorclass 

lnttiallzeAdditionsToDispatchTable 

“Initialize additional keyboard dispatch keys." 

"ParagraphEditor initializeDispatchTable. 

Paragraph!; ditor initdalizeAdditionsToDispatchTable." 

Keyboard bindValue:#displayHaltKey: to: #F5. 

Keyboard bindValue:#displayGuardedHaltKey: to: #F6. 
ParagraphEditor 
displayHaltKey: aCharEvent 

“Replace the current text selection with a debugging statement- 
initiated by #F5." 

self appendToSelection: 'self halt.Y withCRs. 
displayGuardedHaltKey: aCharEvent 

“Replace the current textselection with a debugging statement- 
initiated by #F6." 

self appendToSelection: InputState default shiftDown 
ifTrue:[self haltJ.Y withCRs. 

After compiling those methods, be sure to execute 
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PaiagraphEditorinitializeDispatchTable. 

FaragraphEditoiiiiitlaUzeAdditioiLsToDiapatchTable. 

These bindings are valid only for windows created after initializ¬ 
ing, so open a new Browser or Workspace to test the additions. 

For Smalltalk/V, we use keyboard abbreviations. After typing 
an abbreviation, type Shift-Space to expand the abbreviation. 
Execute the following code, customizing as appropriate: 

Smalltalk at: #Abbreviations put:Dictionaiy new. 

Abbreviations 

at: 'gh' put:'(Notifier isKeyDown: VkShift) ifTrue: [self halt] 
at: 'tr puti'CurrentProcess walkbackOn: Transcript max Levels: 1.' 

In Smalltalk/V for OS/2, add the following method: 

TextPane 

characterlnputi aChar 

"Process a character typed by the user." 

| abbrevDict left right c scontinue newline | 
abbrevDict := Smalltalk 
at:#Abbreviations 

ifAbsent: ["self basicCharacterlnput:aChar]. 

(aChar = Space and: [Notifier isShiftDown]) 
ifTrue: [selfgetPMSelection. 
left := right := selEnd -1. 
s := String new. 

[c := self charAt: left. 

(continue := (c notNil and: [c isAlphaNumeric])) 
ifTrue: [s := (String with: c), s], 
continue] 

whileTrue: [left := left - 1]. 
new := abbrevDict at: s ifAbsent: [nil], 
new notNilifTrue: [self selectlndexFrom: left to:right]. 
''selfinsert: new]. 

"■super characterlnput: aChar 

In Smalltalk/V for Windows, copy the text from the TextPane 
method characterlnput: to a new method called basicCharacter¬ 
lnput:. 

TextPane 

basicCharacterlnput: aChar 

"Private - the user typed aChar." 
self isGapSelection 

ifFalse: [selfhideSelection]. 
newSelection := self replaceWithChar: aChar. 
modified :=true. 
self 

selectAfter: newSelection comer; 
makeSelectionVisible; 
displayChangesForCharinput; 
showSelection 

Then, replace the original characterlnput: method with the 
following: 

TextPane 

characterlnput: aChar 

"Process a character typed by theuser." 

| abbrevDict left right c scontinue line new | 
abbrevDict := Smalltalk 

at: #Abbreviations 

ifAbsent: ["selfbasicCharacterlnput: aChar]. 

(aChar = Space and: [Notifier isKeyDown: VkShift]) 
ifTrue: [left := right := selection comer x. 


line := textHolderlineAt: selection corner y 
s := String new. 

[c := line at: left. 

(continue := (c notNil and: [cisAlphaNumeric])) 
ifTrue: [s := (String with: c),s] 
ifFalse: [left := left + 1]. 

(continue and: [left > 1])] 
whileTrue: [left := left -1]. 
new :=abbrevDict at: s ifAbsent: [nil], 
new notNilifTrue: 

[selection 

selectBefore: left @ selection comer y; 
selectTo: right @ selection corner y. 
self replaceWithText: new. 

selection selectAfter: left + new size @ selection comer y. 
self forceSelectionOntoDisplay. 

"nil]]. 

"self basicCharacterlnput: aChar 

Be careful when entering this method in the browser, as mis¬ 
takes will prevent subsequent character input from text panes, 
such as in the bottom pane of the browser. 

CAVEATS 

Please note that the debugging techniques advocated in this ar¬ 
ticle may violate normal programming guidelines. Some of the 
expressions use globals or “private” methods; others, like mov¬ 
ing or warping the cursor, are expressly prohibited by user in¬ 
terface style guides. Use them judiciously. 

CONCLUSION 

While this article has presented a collection of Smalltalk de¬ 
bugging techniques, it is impossible to describe the most 
efficient debugging strategy for any particular situation with¬ 
out knowing where the problem lies. Of course, if you knew 
where the bug was in the first place, you wouldn’t need to de¬ 
bug it. 

These debugging hints won’t make you an expert overnight. 
Effective debugging requires creativity and experience and 
there are few shortcuts, but assembling an arsenal of debugging 
techniques can shorten development time and improve code 
quality. S 
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Figure 2. The relationship between CompiledMethods and the BreakpointMethods 
that represent them. 

pointMethod itself is invisible in the debugging process, since it 
is removed from the execution stack before the debugger 
opens. In addition, BreakpointMethods implement the getSource 
message by returning their client’s source, and so breakpointed 
methods can be browsed directly. 

The new variable agent is needed to make CompiledMethods 
with breakpoints print out well. Every CompiledMethod has an 
instance variable called mclass, which refers to the class in 
whose method dictionary the CompiledMethod should be 
found. When CompiledMethods print themselves out, they look 
in their mclass to make sure they really are defined there ; if 
they aren’t, they will print out as an unboundMethod. Since 
BreakpointMethods replace their client in the method dictio¬ 
nary, all breakpointed methods would print out as unbound- 
Methods, which is confusing and aesthetically unpleasing. We 
solved this problem by adding agent:. Now, when a Compiled¬ 
Method prints out, it checks to make sure that its agent is 
defined by its mclass, and if so it prints out normally. Most 
CompiledMethods are their own agents, but breakpointed 
methods will have their agent set to the BreakpointMethod 
that’s representing them, and so they’ll print out correcdy. 
Figure 2 illustrates this relationship between CompiledMethods 
and the BreakpointMethods that represent them. 

In Figure 2, the asSeconds method for Date—the Compiled¬ 
Method marked A—is a normal method. Its mclass is Date, it is 
its own agent, and it is referred to directly by Date's method 
dictionary. However, a breakpoint has been placed on the day 
method for Date. The #day entry in Date’s method dictionary 
refers to the BreakpointMethod B, whose clientMethod is the 
CompiledMethod C. CompiledMethod C, in turn, refers to Break¬ 
pointMethod B as its agent. This way, even though Compiled¬ 
Method C is not referenced by Date’s method dictionary, its 
agent—BreakpointMethod B—is, so CompiledMethod C will print 
as a well-defined method rather than as an unbound one. 


We added breakpoints to the system by creating three 
new methods in Behavior, thus making breakpoints in all 
kinds of classes, including instances of both Class and 
LightweightClass. The first method, isBreakpointAt:, tells 
whether the specified method in the Behavior has a break¬ 
point set or not. The second, breakpointCompilerClass, returns 
BreakpointCompiler, which is the compiler used for all classes 
to create new breakpointed methods. The third method, set- 
BreakpointAt:, is the main one and is used to set or remove a 
breakpoint. It’s implemented as: 

setBreakpointAt: aSelector 

I cm ( 

c := self whichClassIncludesSelector: aSelector. 
c isNil ifTrue: [ A self]. 
m := c compiledMethodAt: aSelector. 
self == c 
ifTrue; [ 

m isBreakpoint 

ifTrue: [m client mclass = self 

ifTrue: [self addSelector: aSelector 
withMethod: m client] 
ifFalse: [self removeSelector: aSelector]] 
ifFalse: [self addSelector: aSelector withMethod: 
(BreakpointMethod on: m 
selector: aSelector 
inClass: self)]] 

ifFalse: [ 

m isBreakpoint ifTrue: [m := m client], 
self addSelector: aSelector withMethod: 

(BreakpointMethod on: m selector: aSelector inClass: self)] 

If the receiver Behavior is the class that defines the method cor¬ 
responding to the parameter selector and if the method is al¬ 
ready breakpointed, the code removes the breakpoint by test¬ 
ing whether the BreakpointMethod’s client is defined in the 
receiver or not. If it is, the BreakpointMethod is replaced by its 
client in the receiver’s method dictionary; but if it isn’t, the 
BreakpointMethod is simply removed from the receiver’s 
method dictionary (thus leaving the client in whatever other 
method dictionary it resides). If the method isn’t break- 
pointed, the code creates a new BreakpointMethod for it and 
adds it to the receiver’s method dictionary. Finally, if the 
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method corresponding to aSelector isn’t defined in the receiver, 
a new BreakpointMethod is created and installed in the re¬ 
ceiver’s method dictionary. 

As with lightweight classes, we need a new compiler class, 
BreakpointCompiler, to implement breakpoints. Once again, 
though, this class is almost trivial, since it only needs to define 
newCodeStream to return a CodeStream that creates Breakpoint- 
Methods. 

PUTTING THINGS TOGETHER 

To exploit the functionality provided by IightweightClass and 
BreakpointMethod, we adapted the interface to make object de¬ 
bugging as simple as possible. This required changing the exist¬ 
ing Browsers, adding a menu option to Inspectors, and creating 
a new Browser specifically for lightweight classes. 

The existing Browsers were changed by adding a breakpoint 
option to the menu in the selector view. Choosing this option 
will either set a breakpoint on the selected method or, if the 
method is already breakpointed, remove the breakpoint, so 
that the option acts like a toggle switch. Furthermore, the se¬ 
lector view allows method selectors to be formatted, and we 
use a preceding asterisk to quickly distinguish methods with 
breakpoints. 

In addition, all Inspectors now have a new menu option 
called browseLightweight. Choosing this option will create a 
new lightweight class for the selected object and open a 
IightweightClassBrowser to examine and modify methods for 
that particular object. 

IightweightClassBrowser is a subclass of Browser for looking 
at lightweight classes. As shown in Figure 3, the Lightweight- 
ClassBrowser has six subviews. The first two views allow you to 
decide what methods you’ll see: You can either see only meth¬ 
ods defined in the lightweight class, or all methods up to some 
specified superclass. The upper right view shows which class 
you’re listing methods up to, while the upper left view shows 
which class the selected method is actually defined in. This 
option makes it easy to view a superclass method and then 
make changes to save in the lightweight class. The third view 
lists all selectors from the lightweight class up to the class cho¬ 
sen in the upper right view. These selectors are formatted so 
that all breakpointed methods are marked with an asterisk, 
and so that all methods actually defined in the lightweight 
class (as opposed to one of its superclasses) are printed in 
bold. The fourth view is a TextView on the code of the cur¬ 
rently selected method. Finally, the last two views belong to an 
Inspector on the object whose lightweight class is being 
browsed. 

This interface makes it easy to imagine how the debugging 
session mentioned in the introduction would proceed. Once 
you’ve decided there is a problem with one of your OrderedCol- 
lections, you can use a Browser to put a breakpoint on the 
method where the OrderedCollection is created. When that 
method is executed, a Debugger will pop up. The Debugger lets 
you inspect the OrderedCollection and choose the browse- 
lightweight option to create a lightweight class for it. The 


IightweightClassBrowser lets you put breakpoints on the add: 
and remove: methods. After you “proceed” from the Debugger, 
you’ll be able to watch as that one OrderedCollection is 
modified, and you can find out when objects are added to it 
and when they’re removed. With that information, you’ll be 
well on your way to solving the problem. 

These changes significantly improve debugging in the 
Smalltalk environment. Though breakpoints are convenient, 
it’s the functionality of lightweight classes that makes the key 
difference, as they allow you to monitor or alter the behavior 
of particular objects without affecting the rest of your system. 
The changes described here, while not complex, are remark¬ 
able in one sense, because they rely on our ability to modify 
parts of the Smalltalk system that in some languages would be 
internal and unavailable to programmers. The fact that 
classes are first-class objects—which is to say, classes are ac¬ 
cessible to and modifiable by the programmer—allowed us to 
introduce a new kind of class and to replace an object’s class 
on the fly during execution. Similarly, we were able to create 
two subclasses of CompiledMethod, and make an important 
change to that class itself, only because compiled methods are 
first class. Finally, Smalltalk’s representation of the Compiler 
itself, and its good design for pluggability, allowed us to cre¬ 
ate two simple subclasses by defining only one method each. 
The combination of the ease of making these changes with 
the significant benefits they provide is a good argument for 
the desirability of this level of reflection in a programming 
system. In our next article, we plan to explore one level 
deeper into Smalltalk’s reflectiveness by changing the com¬ 
piler and the interpreter to introduce active variables and 
watchpoints. El 
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Excerpts from industry publications 


COBOL TO OOP 

What would you say if your boss ordered you to transform 60 
mainframe programmers into object-oriented programmers in 
one year? Most likely, “You’re joking, right?” Believe it or not, 
in the past year American Management Systems (AMS) of Ar¬ 
lington, Va., has transformed over 60 COBOL programmers 
into Smalltalk GUI programmers. They didn’t raid the staff of 
an OOP tools firm, and they didn’t rely heavily on external 
consultants. But they did perform a major paradigm shift on 
the minority of their staff... The secrets of their success in¬ 
cluded: Boot camp: All programmers went through develop¬ 
ment tool training and object-oriented design training. The 
majority participated in a one- to eight-week apprenticeship 
program, where they worked side by side with object-oriented 
pros. The process was supportive and orderly—at no point did 
programmers feel they were floundering. Teamwork: AMS 
brought in OOP design dn programming experts to “mind- 
meld” with their COBOL programmers. The experts designed 
the application architectures and classes; the novices handled 
the specialized processing and application logic. The OOP 
novices with GUI design expertise did the screen layout. The 
managers performed function-point analysis to glean new pro¬ 
ject-estimation metrics- AMS effectively used consultants to 
jump-start their efforts, without paying a fortune. Today they 
have a core team of strong OOP technicians in-house.. . 

Bringing object-oriented technology to the masses, 
Christine Comaford, PC Week, 2/27/93 


THEY SAY WE HAVE A REVOLUTION 

We are currently in the middle of a revolution in the Smalltalk 
world Back in the old days the only objects that came with any 
language were simple data structures, enough metaobjects to 
write the system itself, and support for rudimentary graphics and 
user interfaces. Everyone who used an object language was in the 
business, by necessity, of creating fundamentally new kinds of 
objects all the time. This limited users to those who were capable 
of such invention,a nd limited the productivity of those users be¬ 
cause writing new kinds of things is so much harder than reusing 
existing frameworks. A consensus has grown recently that the 
time has come to stop focusing exclusively on creating objects 
and start supporting people who only want to use or elaborate on 
things that already exist. Several factors contributed to this shift: 
The market of wizards creating new frameworks from scratch 
was getting saturated. The economics of growth dictates a search 
for new kinds of customers. The pace of innovation in user inter¬ 
faces slowed, with the major windowing systems settling on 
roughly the same set of components. This allowed the Smalltalk 


vendors to stop spending so much energy doing the entire user 
interface without help from the operating system. Enough ob¬ 
jects had been created that is was possible to imagine someone 
writing an application and not having to create new kinds of ob¬ 
jects. The factors that used to single out Smalltalk—a bundled 
class library and an interactive programming environment— 
were no longer unique. Smalltalk had to move on or get tram¬ 
pled by the Borland C++’s of the world... 

Whole lotta Smalltalk, Kent Beck, 
Object Magazine, 3-4/93 


CORBA 

About 60 companies are creating CORBA implementations, ac¬ 
cording to the Object Management Group. But only DEC and 
HyperDesk, Westborough, Mass., with its Distributed Object 
Management System, are shipping CORBA 1.1 products... HP’s 
implementation, to be called HP Distributed Smalltalk, is a set of 
Smalltalk classes for use with VisualWorks, a Smalltalk develop¬ 
ment environment from ParcPlace Systems.,. 

HP Tool Showcases Key Object Spec, Dan Richman, 
Open Systems Today, 2/15/93 


OBJECT SQL 

DBMS: Are you planning an object-oriented language? Or do 
you recommend one? 

[R&D section manager for HP’s Database Lab, and second 
chairman of the SQL Access Group: John R. Robertson] :The 
real issue is’moving into that paradigm. Yes, we should have 
standards, we should have a common language. I don’t think 
C++ is necessarily the right language. By the time you get into 
object systems you probably want to be having 4 GLs that are 
going to take care of it for your. We should've learned that les¬ 
son by now. We are not making an object-oriented language. 
We have an object-interactive language, which really operates 
at the command level. We’re working with third parties who 
are in the 4GL business. The Object Management Group work¬ 
ing group seems to be migrating toward having a common 
command set, which is OSQL [Object SQL]. I don’t think it 
matters much whether you express that through C++ or 
Smalltalk. The real issue is that you want your object model to 
let you move your methods out of your application and put 
them into the database where you can reuse them. This is how 
database technology will mature. 

Hewlett-Packard's Relational/Object Paradigm, 
Peggy Watt and Joe Celko, DBMS, 2/93 
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SERVIO TO SUPPORT GEMSTONE ODBMS, GEODE 
DEVELOPMENT ENVIRONMENT ON WINDOWS NT. 

Servio Corporation has announced that it will provide support 
for its full range of products on Microsoft Corporation’s Win¬ 
dows NT operating system. 

GemStone and GeODE for Windows NT are scheduled for 
production shipment beginning in early 1994. They are cur¬ 
rently available for most leading UNIX-based platforms in¬ 
cluding Sequent Symmetry 2000, SUN SPARC, RS6000, and 
HP9000, GemStone release 3.2 and GeODE release 2.0. Gem- 
Stone is also available for DEC VAX/VMS. GemStone data can 


be accessed from most client environments including UNIX, 
Windows, OS/2, and Macintosh. 

Servio Corporation develops and markets the GemStone 
object database management system, which incorporates the 
GeODE code-free visual development environment for rapidly 
building and deploying end-user database applications. Servio 
supports its products with consulting on-site technical support 
and educational services that enable customers to implement 
mission-critical object-based solutions. 

Servio Corp., 2085 Hamilton Ave., Ste. 200, San Jose, CA 95125, 
408.879.6200 (v), 408.869.0422(0 


»WANTED» 

BOOK AUTHORS 

Is currently seeking Authors for its 

"Advances in Object Technology" 
series. 

Opportunity to join rapidly growing list of 
prestigious authors and experts and 
earn international recognition. 

To discuss your ideas for a book contact: 

Dr. Richard Wiener, Book Series Editor 
135 Rugely Court 
Colorado Springs, CO. 80906 

© Phone & Fax: 719.579.9616 


The first multi-dialect 

Smalltalk 

developers 
conference 


•De/Ialk 



August 20-21, Glendale, California. 

Presentations ■ Panels ■ Tutorials ■ Technical 
sessions ■ Exhibits • Books & Magazines. 

Digitalk (Smalltalk/V) ■ Servio ( GemStone ) ■ 
Easel (ENFIN) ■ Quasar ( SmalltalkAgents ) ■ 
ObjectShare ( WindowBuilder ) ■ ParcPIace 
(ObjectWorks ) ■ many others. 

Only $250 if you register before July 30! $300 after. 

For more information and a registration form, contact 
Monica at (tel) 213-257-5670, (fax) 213-25943430, or 
(CompuServe) 72330,1236. 










THE TOP NAME 
IN TRAINING IS ON 
THE BOTTOM 
OF THE BOX. 


Where can you find the 
best in object-oriented training? 

The same place you found 
the best in object-oriented 
products. At Digitalk, the 
creator of Smalltalk/V. 

Whether you're launching 
a pilot project, modernizing 
legacy code, or developing a 
large scale application, nobody 
else can contribute such inside 
expertise. Training, design, 
consulting, prototyping, 
mentoring, custom engineer¬ 
ing, and project planning. For 
Windows, OS/2 or Macintosh. 
Digitalk does it all. 


ONE-STOP SHOPPING. 


Only Digitalk offers you a 
complete solution. Including 
award-winning products, proven 
training and our arsenal of 
consulting services. 

Which you can benefit 
from on-site, or at our 
training facilities in Oregon. 
Either way, you’ll learn from a 



DIC 


staff that literally wrote the 
book on object-oriented 
design (the internationally 
respected "Designing Object 
Oriented Software"). 

We know objects and 
Smalltalk/V inside out, because 
we’ve been developing real- 
world applications for years. 

The result? You'll absorb 
the tips, techniques and 
strategies that immediately 
boost your productivity. You’ll 


100% PURE OBJECT TRAINING. 


reduce your learning curve, 
and you’ll meet or exceed 
your project expectations. All 
in a time frame you may now 
think impossible. 


IMMEDIATE RESULTS. 


Digitalk’s training gives 
you practical information and 
techniques you can put to 
work immediately on your 
project. Just ask our clients 
like IBM, Bank of America, 
Progressive Insurance, 
Puget Power & Light, U.S. 
Sprint, plus many others. 
And Digitalk is one of only 
eight companies in IBM’s 
International Alliance for 
AD/Cycle — IBM’s software 
development strategy for the 
1990’s. Fora full description 
and schedule of classes, call 
(800)888-6892x411 

Let the people who put 
the power in Smalltalk/V, help 
you get the most power out of it. 


DIGITALK 





